-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add separate checkout info block to buildscripts. #3483
Conversation
Of the form: ``` Project: URL Time: time ```
To do this, we need callers to pass in the project namespace.
Also rename Get and Set methods to be for commit IDs.
5a1ceb5
to
e504147
Compare
pjf := NewProjectField() | ||
pjf.LoadProject("https://" + host) | ||
pjf.SetNamespace(params.Owner, params.Project) | ||
if params.BranchName != "" { | ||
q.Set("branch", params.BranchName) | ||
pjf.SetBranch(params.BranchName) | ||
} | ||
|
||
u.RawQuery = q.Encode() | ||
params.ProjectURL = u.String() | ||
params.ProjectURL = pjf.String() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to avoid code duplication. I was using NewProjectField()
in the buildplanner to construct the "Project" field in the checkout info block of buildscripts, and found that we can do the same thing here.
Test failure is unrelated to this PR. |
This reverts commit e036299.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see comment on the Initialize function. I didn't finish the review as I imagine this comment may bring about some significant changes.
We need to keep them separate.
4259078
to
b1bb954
Compare
Call out to build scripts to get and set commit IDs instead of using another package. The build script packages will determine if build scripts are enabled and use a mediator if necessary.
I expect more churn. I'm flagging for early review as I doubt it'll pass all tests in its present state, but the idea is in place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things stand out to me at a high level:
- I think checkoutinfo should probably be a primer property
- Because the reliance on cfg already implies primer anyway, and similar to project/projectfile this will almost always be relevant for every command.
- We're still sourcing project URL info from the project package
- eg. owner, name and branch are still being sourced from
project
. I'd expect to see these sourced fromcheckoutinfo
, and have legacy methods on the project methods like we did with the commitID. These legacy methods should probably only be called from checkoutinfo, but there might be edge cases.
- eg. owner, name and branch are still being sourced from
"github.com/ActiveState/cli/pkg/checkoutinfo" | ||
) | ||
|
||
func CommitID(path string, cfg configurer) (strfmt.UUID, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this to checkoutinfo? I get where you're coming from, but runbits are about sharing controller logic. This isn't controller logic. And this type of muliplexing is exactly what the checkoutinfo package is intended for.
b3810dc
to
a8c8a35
Compare
… initialize and update build scripts.
a8c8a35
to
6b174f8
Compare
…ldScript()` method.
I made checkout info a primer property and I think I addressed your other line item (sorry if I overlooked it; lots of changes). I've updated the PR description with an overview of the entire thing. |
} else if !errors.Is(err, ErrBuildscriptNotExist) { | ||
return "", errs.Wrap(err, "Could not get build script") | ||
} | ||
// Fall back on activestate.yaml. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the buildscript exists then I think we should just fail here. Falling back to the as.yaml at that point is working around some bug.
return c.project.Owner() | ||
} | ||
|
||
func (c *CheckoutInfo) Name() string { | ||
return c.project.Name() | ||
} | ||
|
||
func (c *CheckoutInfo) Branch() string { | ||
return c.project.BranchName() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should behave the same as the CommitID()
function; ie. collect from buildscript if opted in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also their Set()
methods should be in checkoutinfo
also.. otherwise we're not syncing the buildscript when those are changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to remove the Owner()
, Name()
, and Branch()
accessors since they're not used externally. The ACs make no mention of having checkoutinfo being the gatekeeper of accessors, just for setters like you mentioned here.
If we make checkoutinfo the sole source of truth for Owner, Name, and Branch, then this PR will double in size. I'd rather do that in another ticket.
if !fileutils.FileExists(buildscriptPath) { | ||
return c.InitializeBuildScript(commitID) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please error out with the "run state reset LOCAL" error. This file should exist if opted in, it not existing is an error condition. Working around this magically like this is what we did originally and it caused a lot of issues.
return strfmt.UUID(commitID), nil | ||
} | ||
|
||
func (c *CheckoutInfo) BuildScript() (*buildscript.BuildScript, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about having this, UpdateBuildScript()
, and InitBuildScript()
inside checkoutinfo
. Checkoutinfo is from a consumer point of view about project information, not about buildscripts, that's just an under the hood mechanic.
Also, we don't handle project retrieval or initialization in this package, so handling buildscripts here feels inconsistent.
Let's put it this way: if we KNOW we want a buildscript, or a project/projectile (the pkg) then we should not be using checkoutinfo
.
This is a mess. I'm going to restart. |
Restarting is more of a mess, so this'll have to do. |
No, I can't do it in this PR. I'll start from scratch. |
localcommit
package tocheckoutinfo
checkoutinfo
is a primer property and all runners go through it to get commit IDs and work with build script (initialize, update, etc.).runbits/buildscript/file.go
in favor of this package.buildplanner.GetBuildScript()
to additionally accept an owner, project, branch, and commitID. It uses these fields to construct the "Project" field in the commit info section of buildscripts.state reset LOCAL
will always re-initialize a build script.state install
, etc.).